The Standish Report tells that in 1994 ninety-one per cent (91%) of software projects failed, with thirty per cent (30%) ultimately cancelled. In 2020, 26 years later, seventy-one per cent (71%) of software projects are considered failures, with seventeen per cent (17%) being completely cancelled. The single most significant factor for these projects is the failure to scale as requirements have changed through their development cycle.
Given the lack of improvement in 26 years of software development, it’s clear we need to find a way to bring more agility to our requirements, and how these can be tracked and traced back to the final implementation.
In a real-world project, requirements can change for several reasons:
- Missed feature
- Didn’t understand the actual need
- Defect
- Changes in the marketplace
- Political
- Regulatory or legislative changes
As a result, trying to “freeze” requirements too early in the lifecycle will ensure that the end product will be what they thought they initially wanted, rather than what people need. The impact of this means: We will build a high-quality product, but low-value. This is not a good strategy for success. To quote Edward Demming, “You don’t have to change, survival is not compulsory.”
How should you handle requirements change?
The key to address changing requirements is to have a streamlined process for working through and managing the ongoing changes. If we consider Agile methodology, it guides us in developing high-quality and high-value software. We can lean on these Agile principles to find a suitable process for handling changing requirements.
The approach taken by Agile is to implement the highest priority requirements first, enabling maximization of stakeholder Return on Investment (ROI). If we look at Scrum, one of the Agile software development frameworks, it treats requirements management like a prioritized stack called a product backlog. Disciplined Agile Delivery (DAD) expands on Scrum by recognizing that developers’ activities aren’t just working on requirements. As part of a developer’s daily job, they also do other non-requirement related work such as taking training, go on vacation, review products of other teams, and address defects.
In DAD, the development teams are presented with a stack of prioritized and estimated work items, including requirements which need to be addressed. New requirements that are introduced, including defects for verification and validation activities, are prioritized by the stakeholders, while developers have the responsibility for estimating the effort. Depending on the priority assigned, the items will be placed higher or lower in the stack. When an item is a non-requirement, the priorities are negotiated between the team and the stakeholders, with non-requirement items being implemented during gaps in the schedule.
Using traceability to understand the impact of changes
While having a process to prioritize and manage requirements changes will help us build a high-value product, one of the risks is that we are unable to understand the impact of the change in requirements fully, and therefore miss aspects when we validate the product. The result will be a high-value low-quality product, which will quickly erode to a low-value low-quality product. This is where having traceability through the different stages of the software lifecycle can be valuable. Traceability is the ability to relate aspects of project artifacts to one another, and a requirements traceability matrix is the artifact that is often created to record these relations. It starts with individual requirements and traces them through any analysis models, architecture models, design models, source code, or test cases that are maintained. The risk with implementing traceability is that data can be replicated in many different areas/stages of the workflow. This can make it much harder to make changes as they must be mirrored multiple times over for a single change to be complete. It is much better to have a single source of truth and have linkages back to this.
It would be typical that a single source of truth would be an Application Lifecycle Management (ALM). Depending on how formal or rigid the compliance requirements are for the product under development, requirements may be captured in a Requirements Management capability inside the ALM tool, or, more simply, in an issue tracking capability. The key is then to link to these items from the different artifacts in the lifecycle; design, unit testing, integration testing, system testing, etc. The process of linking is typically done using a capability known as a Requirements Gateway. A Requirements Gateway is a bridge between the ALM tool and the tool(s) used to manage the different lifecycle artifacts. Figure 2 shows us an example of a traceability workflow, which allows us to use the ALM tool as a single source for our requirements and put linkages, in this example, into our test cases and test results.
Once all the links are put in place, a traceability matrix (see figure 3) gives an overview of all trace items of the project and their test case links. By this overview of test design coverage, you can easily see, for example, which trace items are not covered yet by any test case implementation. Furthermore, using the traceability matrix, it will be easy to navigate from a trace item to linked test cases. This traceability matrix can be used to determine the impact of changes to requirements. Using the impact information, accurate estimates can be established for changes before any prioritization takes place. Once the work has started, ensure that all impacted elements have been correctly updated.
By linking this traceability information to a Continuous Integration / Continuous Delivery (CI/CD) platform, it will also allow for planning which test cases should be (re)executed to validate the end product, with the subsequent results automatically pushed back to the ALM platform.
Conclusion
By leaning on Agile, we’ve discussed a simple process of requirements prioritization which can enable projects to produce high quality and high-value software. More broadly, this workflow is essential because it not only accounts for changes in requirements but also recognizes that there are many activities associated with a developers work in delivering software.
To ensure that we fully implement all changes associated with changes to requirements, we can implement traceability. A traceability matrix can be used to track relationships between requirements and all elements in the software development lifecycle. This will also allow us to accurately determine the impact of any changes as part of our estimation.
Warning signs that your project may have a problem with handling changes in requirements:
- The project is specified in significant detail before any development work begins
- Deep or thorough reviews and concrete sign-offs from all teams are required before work commences
- Architects and developers are unaware of changes to requirements
- Product owners develop requirements without the partnership of the other teams
